When a user interacts with sites on the Internet (hereafter referred to as “service providers” or “relying parties”), the service provider often expects to know something about the user that is requesting the services of the provider. The typical approach for a service provider is to require the user to log into or authenticate to the service provider's computer system. But this approach, while satisfactory for the service provider, is less than ideal to the user. First, the user must remember a username and password for each service provider who expects such information. Given that different computer systems impose different requirements, and the possibility that another user might have chosen the same username, the user might be unable to use the same username/password combination on each such computer system. (There is also the related problem that if the user uses the same username/password combination on multiple computer systems, someone who hacks one such computer system would be able to access other such computer systems.) Second, the user has no control over how the service provider uses the information it stores. If the service provider uses the stored information in a way the user does not want, the user has relatively little ability to prevent such abuse, or recourse after the fact.
To address this problem, new systems have been developed that allow the user a measure of control over the information stored about the user. Windows CardSpace™ (sometimes called CardSpace) is a Microsoft implementation of an identity meta-system that offers a solution to this problem. (Microsoft, Windows, and CardSpace are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.) A user can store identity information with an identity provider the user trusts. When a service provider wants some information about the user, the user can control the release of information stored with the identity provider to the service provider. The user can then use the offered services that required the identity information.
While this system simplifies the management of information used to satisfy the requests of service providers, there are potential problems. For example, when a user visits a relying party on a website that requests a security token to proceed, the user is prompted to select an information card by the card selector. From the user's perspective, the card selector may seem to appear on the user's computer screen unexpectedly and without warning. If the user is not experienced with how the information card system operates, the user might think the card selector appeared on the screen by mistake, and might close the card selector instead of selecting an information card. Further, if the user is running a standalone (non-browser) application such as an e-mail management application, the appearance of a foreign card selector which appears very different from the standalone application being run can result in an equally, if not more, awkward user experience. This could lead to the browser indicating that the relying party refused to let the user continue. Again, if the user is inexperienced, the user might attribute his or her failure to access the resource of the relying party on the relying party, rather than on the user's inexperience with the information card system.
A need remains for a way to addresses these and other problems associated with the prior art.